Emergency location informer system

ABSTRACT

An emergency location informer system includes: an emergency mobile positioning (EMP) server; an emergency service number (ESN) database server storing civic addresses and associated tags that are provided by an internet service provider (ISP) over the IP network; a wireless access point (AP) EMP-AP component executing on a processor of an AP at a civic address known to the ISP, the EMP-AP component providing a tag, known to the ISP, forming a part of a radio frequency (RF) beacon signal transmitted by the AP; and a mobile operating system (OS) EMP-OS component executing on a processor of a cell phone and operative to monitor the beacon signal of the AP and to store the tag, the EMP-OS component being further operative to embed the tag in an emergency call from the cell phone to the EMP server over a network.

CROSS REFERENCE TO RELATED APPLICATION(S)

This application is a continuation of copending U.S. Ser. No.15/788,749, filed Oct. 19, 2017, issued as U.S. Pat. No. 10,187,756 onJan. 22, 2019, incorporated herein by reference.

BACKGROUND

Traditionally, telecommunications have been performed over the publicswitch telephone network (PSTN). A system to maintain addresses andother location information of the subscribers of telecommunicationscompanies operating on the PSTN was developed to provide addresses andlocations to emergency first responders. Determining the location ofsubscribers of the telecommunications companies was relatively easy asthe locations of telephones were known by the telecommunicationscompanies or carriers due to installing the telephones, establishingbilling, or otherwise.

Telecommunications have been changing rapidly over the past severalyears, primarily since the development and growth of the mobiletelephone industry. As a result, the predominant manner in whichconsumers communicate has changed and the ability of an EmergencyService Number (ESN) server to associate a location or address with aphone number is not possible. Mobile devices now account for over 70% ofemergency calls, and with existing location methodologies an ESN servercan only provide, at best, an estimated location represented by a circleon a map, as opposed to a verified civic address, e.g. an officialstreet address of a dwelling or building.

New forms of telecommunications including Voice Over Internet Protocol(VOIP) have been developing as well. With the new forms oftelecommunications, subscribers are able to use wireless devices thatmay access different wireless access points to communicate over acommunications network, such as the internet. For example, UnlicensedMobile Access (UMA) allows internet protocol (IP) access to corenetworks of many mobile carriers. The primary method for locating awireless device using UMA access is by using the Global PositioningSystem (GPS) functionality of the device. However, GPS has limitedaccuracy, particularly in urban areas where the bulk of emergency callsoriginate.

One common interface for wireless access to a communications networkincludes an IEEE 802.11 communications protocol, which is commonly knownas WiFi, and within the industry as Unlicensed Mobile Access (UMA).Standards for UMA have been established between the mobile industry andWiFi industry associations. Wireless devices are being configured tohave WiFi communications protocols to enable a subscriber to access WiFienabled access points. Many WiFi enabled wireless devices have globalpositioning system (GPS) capabilities that are able to communicate theGPS location information (i.e., latitude and longitude coordinates) ofthe WiFi enabled device. While GPS location information may be helpfulto track or locate a person at an estimated geographical location, suchinformation is not extremely useful in an emergency situation whereemergency rescue teams, such as firemen and police, better understandcivic address (e.g. street address) information for performing anemergency rescue in an emergency situation.

A public safety answering position (PSAP), or emergency call center, isused by emergency services to answer calls from the public to notifyemergency personnel, such as police or firemen, to respond to anemergency situation. Traditionally, a caller contacts a PSAP by dialing911 (or 112 in Europe) and provides location information during thetelephone call. When caller identification (i.e., caller ID) wasintroduced, PSAPs were installed with telephone systems compatible withcaller ID to identify names and phone numbers of individuals placingemergency 911 calls. This first version of caller ID is known as type Icaller ID. Type I caller ID operates in a single data message format(SDMF) as well as multiple data message format (MDMF) that provide acaller's telephone number, date and time of the call during the ringinginterval. A second type of caller ID or type II caller ID was laterdeveloped to communicate name and address information of a secondcalling party to a called party when a call between a called party and afirst calling party is in progress. Type II caller ID uses a multipledata message format (MDMF) that communicates a caller's name, telephonenumber, date and time.

Enhanced 911 (E911) is a North American Telephone Network (NATN) featureof the 911-emergency-calling system that uses a reverse telephonedirectory provided by cellular telephone companies to determine locationinformation of a caller. There are two types of E911 systems thatoperate within the United States, namely, Phase I and Phase II. E911Phase I systems are required to provide an operator with the telephonenumber, originator, and location of the cell site or base stationreceiving a 911 call. E911 Phase II systems are required to use anautomatic location identification (ALI). However, only 18% of all PSAPsare configured with E911 Phase II systems. The remaining 82% of PSAPsare configured with E911 Phase I systems, which are incapable ofhandling GPS coordinates, and, therefore, subscribers who have wirelesstelephones that use GPS coordinates for 911 emergency calls cannot beproperly serviced by these PSAPs. If a caller is using a non-cellularwireless device, such as a WiFi enabled wireless device, an operator ata PSAP with E911 Phase I capabilities is unable to determine addresslocation based on GPS coordinates that are received from the caller.Also, because WiFi enabled wireless devices do not communicate via acellular network, there is no cell site or base station locationinformation to be communicated to the PSAP. Furthermore, the billingaddress associated with a cell phone is not necessarily considered thelocation to which emergency responders should be sent, since the deviceis portable. This means that locating the caller is more difficult, andthere is a different set of legal requirements.

Accurate and automatic mobile emergency location is the biggestchallenge in the ESN Industry. As noted above, currently about 70% ofemergency calls come from mobile devices. Current methodologies are allnetwork centric and layered over a cellular network. For example,approximate location can be determined using GPS, Assisted GPS (AGPS),cell tower triangulation, and cell tower signal strength/powermeasurements. Unfortunately, these techniques only provide a roughestimate of a caller's location (e.g. a circle on a map) not adispatchable civic address.

In U.S. Pat. No. 9,179,280, Ray et al. disclose a system and method forproviding location information to a public safety answering point duringan emergency 911 call from a WiFi handset. When a user of a WiFi handsetmakes an emergency 911 call, the GPS location of the handset and itsmobile directory number is received at a network access (WiFi) accesspoint. The WiFi access point adds address information to the GPS andmobile directory number of the handset and send the information to aPSAP over the internet. This is a WiFi handset-only solution, andpresupposes that the WiFi handset can access the WiFi Access pointthrough its security layer, that there is a good connection to theinternet, and that the PSAP is capable of receiving and processinginternet calls.

While the methodology describe above by Ray et al. can work for WiFiphones, cell phones are programmed to use the cellular network totransmit emergency calls. Additionally, WiFi phones are specific to aLocal Area Network (LAN) where a “controller” receives communicationsfrom the Wi-Fi handset, recognizes it is an emergency call and thenobtains location information. While this can be effective for a managedLAN or a controlled environment (e.g. a shopping mall, large corporationor plant) it would not be functional or capable for widespread use.

In U.S. Patent Pub. No. 2017/0171754, South et al. disclose a method forsecure, beacon-based emergency location including detecting, with an appexecuting on a user device, a signal from a nearby beacon, andtransmitting app verification information to the beacon, which thensends beacon verification information including the app verificationinformation to both the user device and an emergency verificationserver. The method also includes authenticating, with the emergencyinformation server, the beacon verification information to verify thatthe user device is physically proximate to the beacon and, if the beaconverification information is authentic, determining the geographicallocation of the user device based upon the geographical location of thebeacon. This solution presupposes that the app is installed, activatedand is functional on the mobile device, that the beacon that the mobiledevice can access the beacon through its security layer (if any), thatthere is good connection to the internet, and that all of theverifications have been met.

This system described by South et al., is believed to be very difficultto implement. Regulatory issues will be many and the anticipated cost todeploy and maintain beacons will be great. Furthermore, the complexityof verifications and/or utilization of public and private keys wouldintroduce many new elements into the current emergency systems thatoperators may be reluctant to implement due to the high costs ofinstallation, maintenance, quality control and system management for anew system.

These and other limitations of the prior art will become apparent tothose of skill in the art upon a reading of the following descriptionsand a study of the several figures of the drawing.

SUMMARY

In an embodiment, set forth by way of example and not limitation, anemergency location informer system includes: an emergency mobilepositioning (EMP) server communicating over a public switched telephonenetwork (PSTN), a cellular network and an internet protocol (IP)network; an emergency service number (ESN) database server storing civicaddresses and associated tags that are provided by an internet serviceprovider (ISP) over the IP network; a wireless access point (AP) EMP-APcomponent executing on a processor of an AP at civic address known tothe ISP, the EMP-AP component providing a tag, known to the ISP, forminga part of a radio frequency (RF) beacon signal transmitted by the AP;and a mobile operating system (OS) EMP-OS component executing on aprocessor of a cell phone and operative to monitor the beacon signal ofthe AP and to store the tag, the EMP-OS component being furtheroperative to embed the tag in an emergency call from the cell phone tothe EMP server over a network; whereby the EMP server receives the tagembedded in the emergency call such that a civic address associated withthe tag can be retrieved from the ESN database server.

In another example, an emergency mobile positioning server includes: aprocessor; a public switched telephone network (PSTN) interface coupledto the processor; a cellular network interface coupled to the processor;an internet protocol (IP) network interface coupled to the processor;memory coupled to the processor, including code segments executable bythe processor including: (a) code segments receiving an emergency callwith an embedded tag via one or more of the PSTN interface, the cellularnetwork interface, and the IP network interface; (b) code segmentsquerying an emergency service number (ESN) database server via the IPnetwork interface with the tag to obtain civic address information; and(c) code segments directing the emergency call with the embedded tag toan emergency call center associated with the civic address information.

An example of a non-transitory computer readable media comprising codesegments executable on a processor of a wireless access point (AP)includes: code segments communicating tag information with an ISPcoupled to the AP at a civic address; code segments embedding the tag ina beacon frame; and code segments transmitting the beacon frame as aradio frequency (RF) beacon signal.

Another example of a non-transitory computer readable media comprisingcode segments executable on a processor of a cell phone including: codesegments monitoring radio frequency (RF) beacon signals for wirelessaccess point (AP) tags that are associated with civic addresses; codesegments storing the AP tags in a memory of the cell phone; codesegments detecting an emergency call being made by the cell phone; andcode segments embedding at least one of the AP tags in the emergencycall.

An advantage of methods and systems disclosed herein is that thelocation of cell phone users making emergency calls can be determinedwith greater accuracy without changing legacy emergency call centers.

Another advantage of methods and systems disclosed herein is that theEMP-OS component is embedded into the OS of a mobile device, whichincludes existing protocols for handling emergency calls.

Yet another advantage of methods and systems disclosed herein is thatthe tag(s) embedded into the emergency call stream by the EMP-OScomponent can be used to determine the location of the caller withoutdisclosing private information.

A still further advantage of methods and systems disclosed herein isthat the location information of access points is provided by a trustedsource, e.g., an Internet Service Provider.

These and other embodiments, features and advantages will becomeapparent to those of skill in the art upon a reading of the followingdescriptions and a study of the several figures of the drawing.

BRIEF DESCRIPTION OF THE DRAWINGS

Several example embodiments will now be described with reference to thedrawings, wherein like components are provided with like referencenumerals. The example embodiments are intended to illustrate, but not tolimit, the invention. The drawings include the following figures:

FIG. 1 is an illustration of an Emergency Services Number (ESN) system;

FIG. 2 is a block diagram of a wireless access point (AP) forming a partof the ESN system;

FIG. 3 is a flow diagram of a process implemented by the AP of FIG. 2;

FIG. 4 is a block diagram of a cell phone with a mobile app;

FIG. 5 is a flow diagram of a process implemented by the mobile app ofFIG. 4;

FIG. 6 is a block diagram of an emergency mobile positioning (EMP)server; and

FIG. 7 is a flow diagram of a process implemented by the EMP server ofFIG. 6.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

In FIG. 1, an Emergency Services Number (ESN) system 10 comprises ESNmobile positioning servers, devices and components including anemergency mobile positioning (EMP) server 12, an emergency servicenumber (ESN) database (DB) server 14, wireless access point (AP) 30, anEMP-AP component 16, and a cellular telephone (cell phone) EMP-OScomponent 18. The EMP-AP component 16 includes code segments that areincorporated into the operating system of an access point, e.g. via anApplication Programming Interface (API), a Software Design Kit (SDK) orotherwise. The EMP-OS component 18 includes code segments that areintegrated into the operating system of a cell phone, such that it isalways active. The ESN system 10 also includes devices, components andsystems of third parties, including the cellular telephone network 20,the internet 22, internet service providers 24, ESN operator stations28, wireless access points (APs) 30 (labeled individual here as 30A,30B, and 30C, by way of examples) and cell phone(s) 32. As used herein,the terms “cell phone”, “mobile device”, “handset” and the like areoften used synonymously.

In this example, there are three residential homes R1, R2 and R3, eachhaving a civic address, and each of which receive internet services fromISP 24. It will be appreciated that in other embodiments, theresidential homes may receive internet services from different ormultiple ISPs. Also in this example, APs 30A, 30B and 30C are locatedwithin homes R1, R2, and R3, respectively, and are thereby associatedwith the same civic addresses as the houses.

In FIG. 2, a AP 30, set forth by way of example but not limitation,includes a WiFi device 34, a Bluetooth device 36, a router 38 having oneor more wired Ethernet connections, a 2.4 G/5 G front end 40, a 5 Gfront end 42, a 2.4 G front end 44, and a duplexer 46. As will beappreciated by those of skill in the art, WiFi is a technology forwireless local area networking with devices based upon the IEEE 802.11(and subsequent advanced standards inclusively) standards. WiFi mostcommonly uses the 2.4 gigahertz Ultra High Frequency (UHF) and 5gigahertz Super High Frequency (SHF) Industrial, scientific and medical(ISM) radio bands. The WiFi device 34 can be, by way of example, an802.11 dual band transceiver and processor, such as the BCM4352dual-band radio made by Broadcom Limited of San Jose, Calif. Coupled tothe WiFi device 34 are electrically erasable, programmable read-onlymemory (EEPROM) 48, a quartz crystal (XTAL) 50, and a direct current(DC) to DC converter 52. A first antenna connection 54 is coupled tofront end 40 and a second antenna connection 56 is coupled to duplexer46.

Both the WiFi device 34 and the Bluetooth device 36 can be programmed totransmit “beacons”, which are used to periodically broadcast informationconcerning at least the presence of the device. In addition, beaconsoften include additional information, such as the network configuration,timing codes, etc.

Infrastructure network access points, such as APs, use beacon frames tosend beacon signals at defined intervals, which is sometimes set to adefault 100 ms. A beacon frame is one of the management frames in IEEE802.11 based WLANs, and includes an Ethernet header, body and framecheck sequence (FCS). Some of the fields of a WiFi beacon frame include:

-   -   Timestamp—after receiving the beacon frame, all the stations        change their local clocks to this time. This helps with        synchronization.    -   Beacon interval.    -   Capability information (16 bits)—capability of the        device/network including type of network, support for polling,        encryption details, etc.    -   Service Set Identifier (SSID) is a sequence of 0-32 octets. It        is used as an identifier for a wireless LAN, and is intended to        be unique for a particular area. It is often a human readable        string entered by a user, aka “network name.”

EMP-AP components 16 comprise code and libraries to embed a “tags” intothe beacon frames of APs 30. The EMP-AP components 16 are generated bythe ISP 24 (or other ISPs) and are loaded into a memory of the APs 30,e.g. in EEPROM 48, and are associated with the known civic address ofthe AP. The EMP-APs 16 may comprise a part of the edge software of theAPs 16, or may comprise software development kits (SDKs) which becomeassociated with the edge software of the access points. It should benoted that the code segments of the EMP-APs 16 do not necessarilycommunicate with the APs 16, in that they may not be able to penetratetheir security layer, and to the extent that there is communication withan AP, such communication is limited. For example, such communicationwould not allow the SSID to be user-modified. Also, the tags generatedby the EMP-APs 16 are preferably not modifiable by the user of themobile device, for security and privacy issues.

The civic address of the WiFi access point is known because it isconnected to a wired internet access point known to the ISP. Forexample, if the internet access point was installed and was servicedwith one or more Universal Resource Locators (URLs) at the civic addressof 123 Main Street, Anytown, Minn., the ISP would know, with somecertainty, that the AP 30 was at that civic address, absent some extrememeasures taken by a user to defeat that certainty. Since the ISP has avested interest in knowing the civic address of the WiFi AP, the ISPbecomes a trusted 3^(rd) party provider (“trusted source”) of accuratecivic address information. In addition to storing the EMP-AP components16 in the APs 30, the ISP trusted source maintains a database of tagsand their associated civic addresses in ESN DB server 14. An ESNoperator 28 can then query ESN DB server 14 with a tag, and retrieve thecivic address associated with that tag.

In FIG. 3, an example EMP-AP component process 16 begins at 60 and, inan operation 62, code segments communicate tag information with the ISP.The tag information can be generated by the AP, or by the ISP, orjointly by the AP and the ISP. The tag information (tag) is associatedwith the civic address of the AP, which is known to the ISP. The AP isalso known to the ISP by, for example, the universal resource locator(s)(URLs) assigned to that AP by the ISP. Next, in an operation 64, the tagis embedded in a beacon frame along with other beacon informationnormally provided by an AP. Finally, the beacon frame is transmitted ona periodic basis in an operation 66 as radio frequency (RF) beaconsignal.

FIG. 4 illustrates, by way of example and not limitation, a cell phone32 including the main circuitry 72 and input/output (I/O) componentssuch as a display 74, a keypad 76, a speaker 78, a microphone 80 and acamera 82. Main circuitry 72 is powered by a battery 84 and is turned onand off with a switch 86. In this example embodiment, the main circuitry72 is provided with a universal serial bus (USB) 88. A transmit/receive(Tx/Rx) switch 90 and a Bluetooth/GPS (BT/GPS) module 92 couple anantenna 94 to the main circuitry 72.

Main circuitry 72 of cell phone 32 includes a processor (CPU) 96,capable of running applications (apps) and read only memory (ROM) 98coupled to the CPU 96. In this non-limiting example, app 58 is stored inROM 98, which can be, for example, an electrically erasable,programmable read only memory (EEPROM) or flash memory. Other memoryinclude random access memory (RAM) 102, and a removable subscriberidentity module (SIM) 100 which identifies the subscriber and device.The example main circuitry 72 also includes a CODEC 104, a basebandprocessing and audio/speech processing digital signal processor (DSP)106, a digital to analog converter (DAC) and analog to digital converter(ADC) 108, and a RF part 110 for frequency conversion, poweramplification, etc.

FIG. 5 is a flow diagram of an example EMP-OS component 18 process. Inthis non-limiting example, code segments of EMP-OS component 18implement a process that begins at 112 and, in an operation 113, it isdetermined if an emergency call is being made on cell phone 32. Forexample, the user of the cell phone may be dialing 9-1-1. If noemergency call is being made, the process 18 idles in operation 113until an emergency call has been initiated.

After operation 113 detects that an emergency call is being made, it isdetermined if an RF beacon signal is detected in an operation 114. Ifoperation 114 detects an RF beacon signal, an operation 115 determinesif the detected RF beacon includes a tag. It should be noted that notall beacon signals detected by EMP-OS component 18 will include tags,e.g. they are beacons from devices that do not include EMP-AP component16 from an ISP. If a tag is detected by operation 115, the beacon frameparameters, including the tag information, are stored in an operation116. Next, an operation 117 retrieves the beacon frame parameters andone or more tags are embedded in an emergency call stream in anoperation 118, if tags are available. It should also be noted that theprocess of EMP-OS component 18 can store information about a number oftags which can be analyzed for usefulness in determining a civicaddress, or which can be forwarded as a group along with an emergencycall. For example, when there are multiple tags, they can be ranked asprimary, tertiary, etc. for location purposes by first responders. Also,with multiple tags, the location of the mobile device can be moreaccurately determined within the multiple WiFi footprints.

With continuing reference to FIG. 5, it is next determined in anoperation 119 if a cellular network is available. If so, the emergencycall stream, with embedded tags, if available, is sent via the cellularnetwork in an operation 120. If the cellular network is not available,an operation 121 determines if a data network is available and, if so,the emergency call stream with the one or more embedded tags, ifavailable, is sent over the data network in an operation 122. If thedata network is not available, it is determined if the internet isavailable in an operation 123 (e.g. via WiFi) and, if so, the emergencycall streams with the one or more embedded tags, if available, is sentvia the internet in an operation 124. If no network is available, anoperation 125 determines that the emergency call has failed. After anyof operations 120, 122 and 124, and operation 126 sends cell phonelocation information to the EMP server using internet protocol (IP). Forexample, a cell phone 32 can send location information such as GPS, AGPSand the WiFi Universal Resource Locator (URL) information over theinternet to the EMP server 12. While in this non-limiting example, thehierarchy of networks is first cellular, second data and third internet,in other embodiments the hierarchy may be different, or the emergencycall stream with the one or more embedded tags may be sent throughmultiple networks or other networks available to the caller.

With additional reference to FIG. 1, and by way of non-limiting example,if cell phone 32 is within R2, it is likely within range of AP 30B.EMP-OS component 18, residing on cell phone 32, is activated by theinitiation of an emergency phone call by the cell phone user. The EMP-OScomponent 18 retrieves the tag (Tag 2) from the beacon frame transmittedby AP 30B, and stores it in local memory, and any other tags that is mayreceive, e.g. from beacon frames transmitted by AP 30A and/or AP 30B.EMP-OS component 18 then embeds the one or more tags (if available) intothe emergency call stream before sending the emergency call over anappropriate network. Additionally, the GPS location of the cell phone 32can also be transmitted to the EMP server 12 via the internet 22 usinginternet protocol (IP). The EMP server 12 then queries the ESN DB 14 todetermine to which ESN portal (“emergency call center”) the call, alongwith its tag, should be sent. An ESN operator 28 of the emergency callcenter then can converse with the cell phone 32 user, while retrievingthe civic address of the user via the ESN DB server 14.

A beacon frame is one of the management frames in IEEE 802.11 basedWLANs. It contains all of the information about the network. Beaconframes are transmitted periodically to announce the presence of awireless LAN. Beacon frames are transmitted by the access point (AP) inan infrastructure basic service set (BSS). In IBSS network beacongeneration is distributed among the stations. Beacon frames include anEthernet header, body and frame check sequence (FCS). Some of the fieldsinclude:

-   -   Timestamp—after receiving the beacon frame, all the stations        change their local clocks to this time. This helps with        synchronization.    -   Beacon interval    -   Capability information (16 bits)—capability of the        device/network including type of network, support for polling,        encryption details, etc.    -   Service Set Identifier (SSID) is a sequence of 0-32 octets. It        is used as an identifier for a wireless LAN, and is intended to        be unique for a particular area. It is often a human readable        string entered by a user, aka “network name.”        In the present example, the EMP-OS component 18 is preferably        unable to rename the SSID.

In FIG. 6, an example emergency mobile positioning (EMP) server 12includes a processor (CPU) 127, a public switched telephone network(PSTN) interface 128 coupling a PSTN to the processor 127, a cellnetwork interface 129, and an IP network interface 130 coupling an IPnetwork to the processor 127. In some examples, the IP network includesthe internet, and in other examples the IP network is a virtual privatenetwork (VPN). It should be noted that other networks can also becoupled to the CPU 127, to the extent that they are now or in the futureare available. For example, legacy and video inputs can also be coupledto CPU 127. Memory 132, including code segments 134 which helps routethe call to an optimal emergency call center, is also coupled to theprocessor 127.

FIG. 7 is a flow diagram of a process implemented by the code segments134 stored in the memory 132 of EMP server 12. The process 134 begins at136 and, in an operation 138, it is determined if an emergency call iscoming in via the PSTN interface 128. If not, the operation 138 idlesuntil a call does arrive. If there is an emergency call, it isdetermined if there is GPS information associated with that callarriving at IP Network interface 130. If so, the GPS information relatedto the emergency call is stored in an operation 142. The EMP server 12can determine that the GPS information is related to the emergency callin a number of ways, including matching GPS coordinates (and othermobile phone derived location information) with the emergency call, orusing the mobile device phone number or other identifier (e.g. one ormore tags) to match with the voice call.

Next, an operation determines if the emergency call has one or moreembedded tags in an operation 144. If not, the emergency call isdirected based upon the best available information (e.g. GPS, ifavailable) to an emergency call center in an operation 146, after whichprocess control returns to operation 138. If operation 144 does detectone or more embedded tags, an operation 148 optionally retrieves a civicaddress from the ESN DB server 14 based upon the tag(s), and the call isdirected to an ESN operator 28 in an operation 150.

Although various embodiments have been described using specific termsand devices, such description is for illustrative purposes only. Thewords used are words of description rather than of limitation. It is tobe understood that changes and variations may be made by those ofordinary skill in the art without departing from the spirit or the scopeof various inventions supported by the written disclosure and thedrawings. In addition, it should be understood that aspects of variousother embodiments may be interchanged either in whole or in part. It istherefore intended that the claims be interpreted in accordance with thetrue spirit and scope of the invention without limitation or estoppel.

What is claimed is:
 1. Non-transitory computer readable media comprisingcode segments executable on a processor of a wireless access point (AP)comprising: code segments communicating tag information with between aninternet service provider (ISP) coupled to the AP and a wireless accesspoint (AP) located at a civic address, wherein the tag is generated byat least one of the AP and the ISP and is stored, by the ISP, on anemergency service number (ESN) database server along with the civicaddress, whereby the ISP is a trusted source; code segments embeddingthe tag in a beacon frame with other beacon information normallyprovided by the AP; and code segments transmitting the beacon frame as aradio frequency (RF) beacon signal.
 2. Non-transitory computer readablemedia comprising code segments executable on a processor of a wirelessaccess point (AP) as recited in claim 1 wherein the beacon frame is aWiFi beacon frame.
 3. Non-transitory computer readable media comprisingcode segments executable on a processor of a wireless access point (AP)as recited in claim 2 wherein the WiFi beacon frame includes atimestamp, a beacon interval, capability information, and a Service SetIdentifier (SSID).
 4. Non-transitory computer readable media comprisingcode segments executable on a processor of a wireless access point (AP)as recited in claim 3 wherein the capability information includes atleast one of network type, support for polling, and encryption details.5. Non-transitory computer readable media comprising code segmentsexecutable on a processor of a wireless access point (AP) as recited inclaim 1 wherein the beacon frame is a Bluetooth beacon frame. 6.Non-transitory computer readable media comprising code segmentsexecutable on a processor of a wireless access point (AP) as recited inclaim 1 wherein code segments embedding the tag in a beacon framecomprise both code and libraries.
 7. Non-transitory computer readablemedia comprising code segments executable on a processor of a wirelessaccess point (AP) as recited in claim 1 wherein code segments embeddingthe tag in a beacon comprise a software development kit (SDK). 8.Non-transitory computer readable media comprising code segmentsexecutable on a processor of a mobile device comprising: code segmentsdetecting an emergency call; code segments monitoring a radio frequency(RF) beacon signal for a wireless access point (AP) a tag that isassociated with a civic address if an emergency call is detected,wherein the tag and the civil address are stored in an emergency servicenumber (ESN) database server by an internet service provider (ISP),wherein the ISP and the AP communicate tag information over the IPnetwork and wherein the tag was generated by at least one of the AP andthe ISP; code segments storing the beacon frame parameters in a memoryof the mobile device if a tag is detected; code segments retrievingbeacon frame parameters from the memory of the mobile device; and codesegments embedding at the tag in the an emergency call stream. 9.Non-transitory computer readable media as recited in claim 8 furthercomprising code segments for transmitting at least one of globalpositioning service (GPS), Assisted GPS (AGPS) and Uniform ResourceLocator (URL) information via an internet protocol (IP) network afterdetecting an emergency call being made by the mobile device. 10.Non-transitory computer readable media as recited in claim 8 furthercomprising code segments monitoring a plurality of RF beacon signals,storing a plurality of tags in the memory of the mobile device, andembedding multiple tags in the emergency call.
 11. Non-transitorycomputer readable media as recited in claim 10 further comprising codesegments for ranking the multiple tags for location purposes by firstresponders.
 12. Non-transitory computer readable media comprising codesegments executable on a server comprising: (a) code segments receivingan emergency call via one or more of a PSTN interface, a cellularnetwork interface, and an IP network interface; (b) code segmentsdetermining if there is location information related to the emergencycall; (c) code segments storing the location information if there islocation information related to the emergency call; (d) code segmentsdetermining if there is an embedded tag for the emergency call; (e) codesegments directing the emergency call to an emergency call center basedupon available information if there is no embedded tag for the emergencycall; (f) code segments providing bi-directional communication with anemergency service number (ESN) database server via an IP networkinterface, wherein the ESN database server includes and civic addressinformation; and (g) code segments directing the emergency call with theembedded tag to an emergency call center if there is an embedded tag forthe emergency call.
 13. Non-transitory computer readable mediacomprising code segments executable on a server as recited in claim 12wherein the emergency call with the embedded tag is received by an ESNoperator of the emergency call center.
 14. Non-transitory computerreadable media comprising code segments executable on a server asrecited in claim 13 wherein the ESN operator queries the ESN databaseserver with the tag to retrieve the civic address.
 15. Non-transitorycomputer readable media comprising code segments executable on a serveras recited in claim 12, wherein the memory further comprises codessegments executable on the server for receiving at least one of globalpositioning system (GPS), Assisted GPS (AGPS) and Uniform ResourceLocator (URL) information associated with the emergency call via the IPnetwork interface.
 16. Non-transitory computer readable media comprisingcode segments executable on a server as recited in claim 15, wherein thememory further comprises: code segments querying the ESN database toretrieve civic address information; and code segments for verifying thecivic address information with the at least one of global positioningsystem (GPS), Assisted GPS (AGPS) and Uniform Resource Locator (URL)information.
 17. Non-transitory computer readable media comprising codesegments executable on a server as recited in claim 12 furthercomprising code segments receiving an emergency call with a plurality oftags.
 18. Non-transitory computer readable media comprising codesegments executable on a server as recited in claim 17 furthercomprising code segments querying the ESN database server with theplurality of tags to obtain civic address information related to theplurality of tags.
 19. Non-transitory computer readable media comprisingcode segments executable on a server as recited in claim 13 wherein thecommunication with the ESN operator are over an IP network. 20.Non-transitory computer readable media comprising code segmentsexecutable on a server as recited in claim 19 wherein the ESN operatorprovides the tag to the ESN database to obtain the associated civicaddress.